Optimizing Pictures

Overview Introduction Background Pictures Sound Movies Text General

Apple Media Tool uses PICTs or Pictures as the format to display images. This format is very popular on the MacOS platform and thanks to QuickTime for Windows, an AMT title can display the same file on the Windows platform.


picture [1]: Buffered drawing or speed drawing

In figure 2 (Background Information), you have noticed that the 2 pictures are represented differently. When AMT loads a picture it can store it in 2 different ways in RAM: buffered or in the PICT format itself. Buffered means it is optimized for drawing. The InfoPart image is stored in the PICT format which takes more time to draw. You will notice this especially if you compress your images as JPEGs (see more info later on this). The difference in drawing speed can be as much as 20 times. But the buffered format comes at a cost: it uses more memory.

How much:

		(height * width) / 1024 = buffered size in kilobytes.

This is if your title runs in 256 colors. When your title is running in thousands of colors the size is twice as large, and in the case of millions of colors it is 4 times as large.

An example, when you have background images with the dimensions 640 x 480:

		256 colors                300 kilobytes
		thousands of colors       600 kilobytes
		millions of colors        1200 kilobytes

Now when a picture is loaded into memory in the PICT format the image will always occupy the same amount of memory no matter the number of colors. The size it takes is the file size you see in the Finder. When you add a PICT to your Media list, AMT sets it, by default, to buffered. Double click on the PICT media and you will get this dialog:


figure 3: Buffered state of a Picture.

If you are considering to switch off Buffered be aware of this:

picture [2]: Choose the right monitor depth

As soon as your title runs on a higher monitor depth, it will use more memory. When you choose buffered for your images, you should carefully examine the memory use of your application. There is one item we can't control, and that is the memory of the invisible window (or the offscreen). The offscreen is stored in memory in the buffered format, so it is influenced by the same memory consequences as your buffered images.

Drawing speed is also influenced by monitor depth. When your title runs in 256 colors your animations can run smoothly, but as soon as you go to thousands of colors there can be problems. This is understandable when you look at the amount of memory a buffered image takes. When AMT has to draw the offscreen to the monitor it has to move twice the amount of memory in thousands of colors. In the case of millions of colors it is 4 times as much memory. Furthermore, before AMT can draw the offscreen image to your screen, it has to draw your media to the offscreen. And here, of course, the same rule applies. So if your title has to run in higher monitor depths, check your drawing speed.

Not only can you set the monitor depth, you can also store your images in different depths. Of course PICTs stored in thousands of colors (or 16-bit) take up more space then 256 color PICTs (or indexed colors).

Remark: When you startup a title on a Macintosh it will switch your Mac's monitor depth according to your preferred settings.


figure 4: Runtime Setup 256.

In figure 4: your title will first try to find a monitor with a depth of 256 colors; if it can't find a monitor with this number of colors, it will look for a monitor with thousands colors. But there will never be a time when it can find a monitor that supports thousands of colors and not 256 colors. All that this setting is doing is forcing the application to use 256 colors. This is not desirable when the end user does have thousands of colors. So most of the AMT developers use something like this:


figure 5: Runtime Setup Thousands.

But this setting can be very dangerous. When you open your title, it will first try to find a monitor with thousands of colors. Now when your are running on a configuration that doesn't have much memory, for example an 8 MB PowerPC, you can run out of memory easily because some of these PowerPCs support thousands of colors, and thus will use thousands of colors which, as stated before, takes twice as memory for buffered images.

Solution: create a separate application for each monitor depth.

On the Windows Platform it will take the depth currently set by the user, so you don't have this problem.

picture [3]: The resolution of your screen.

A normal title is created for a resolution of 640 x 480, but when your title needs a low memory footprint you could consider reducing your resolution. The offscreen window and your background images will take up less space.

When your resolution is smaller, AMT has to move less memory between the offscreen window and the monitor, which benefits drawing speed.

picture [4]: Black Screen


If you have a one-color background image, don't create a PICT for it but consider using a color object. First create an empty object then change it to a color object.


figure 6: Color Object.

You will use less memory. But if you need fast drawing speed you should use a PICT and mark it as buffered because this will draw about 20% faster. But remember the consequences on memory.

In case you didn't use buffered, but stored your one-color image as a PICT in memory, you should know that a color object draws much faster to the screen.


picture [5]: Splitting up your background image.


Different screens can have different background images. In some cases the difference is only a title bar or a small portion of the the image. By splitting up your background image into separate images you can avoid loading a complete screen every time. But if you split up your image, do it wisely.

Example:


figure 7: Splitting up a background image.

When you split your image, be sure that the areas are rectangular and avoid overlapping areas. These areas are drawn twice to the screen and also use needless memory.

Remark: If you are not using the AMT Accelerator, splitting up can introduce longer load times because you have more files to load, which generates the seek problem of CD-ROM. The problem only occurs when you load these images for the first time, though; the other screens, using the example, will only load "Part 3". The overall effect is a speed gain.

picture [6]: Combining several images into one image.


When you have buttons on your screen, some of these buttons can have different views: MouseDown, MouseUp, MouseLeave, etc. Most of the time, people keep all these buttons in separate files or use flipbooks. If we add now one of the button's Pictures into the background image, your title will use less memory and have less media items to load. Every element that doesn't change its position can be added to the background image.

This is, of course, not always possible; for example, when the background image is used on different screens but not with all the same buttons.

Remark: The loading problem will be solved if you use the AMT Accelerator.


picture [7]: Flipbooks


figure 8: flipbooks.

In AMT 1.2 when you had buttons with different states, you created different PICTs for each of them. Now with AMT 2.0 you have flipbooks, which allows you to store all the different states into one PICT and shows only the right part of this PICT on screen. The load time will be better because you avoid the seek problem.

Remark: if you use AMT Accelerator you don't have this problem.

picture [8]: Compression


The PICT format is a very powerful format because it allows you to store your images under a compressed format. For this it uses QuickTime, which is why some applications call these images QuickTime Stills (see Tools section). Images take up less space when compressed. By reducing the size, load time will become smaller. Also you can use compression to avoid surpassing the capacity of the CD-ROM.

QuickTime supports different kinds of compression methods, also known as Codecs. But different compression methods mean different results, so you just have to experiment.
Facts that can help you make your decision:

a. Size: Different algorithms exist because some of these algorithms work good on certain kinds of images. They all give you different file sizes.

b. Quality: Some of these compression algorithms can only reduce the file size by sacrificing image quality. Always check if the quality is sufficient.

c. Drawing Time: Compressed images take more time to draw. It is possible that by reducing the size of your files, your application will spend less time in reading data from the CD-ROM, but because you choose a very calculation-intensive algorithm, there will be no gain at all in speed or, even worse, it will in fact take more time. Be aware that if you have chosen Buffered for your PICTs (see picture [1] tip) the drawing time you will loose only occurs once, when loading the screen.


figure 9: Compression Codecs


Some Examples:

JPEG

  • industrial standard for compressing photos
  • creates very small file sizes
  • allows you to choose between different qualities
  • takes much time to decompress.

Graphics

  • is good for compressing 256 indexed images
  • you don't loose quality
  • you will loose the custom palette.

Cinepak

  • mostly used for video but is currently becoming very popular for still images, because decompression time is much faster than JPEG.


Before you start compressing all your images I would like to share some tests we did:

In our test title we used exclusive 16-bit (or thousands of colors) Picture media. What you see in the table below are the times between the click on the next screen button and when we actually see the screen. There were 20 Pictures to load; most of them were very small.


figure 10: Compression test

With selective compression we mean that only the media that were larger than a certain size (ex. 120 Kbytes) were compressed.

Tip: The MacOS Finder is very helpful on this. With the Find command you can select all the pictures that are stored in a folder with a certain size. After you've selected a folder and chose the Find command you can select in the Find Items part of the dialog "in the Finder selection". Then the find will only be performed on your selected folder. Afterwards you will get a list of files; just select these files and drag them to an empty folder. Then use one of those batch processing tools (see tools section) to compress the pictures.


figure 11: Find PICTs with large size.

Memory:
When QuickTime needs to draw a compressed picture to the screen it first has to uncompress the picture. The uncompressing uses extra memory (depending on the size of your image). So you only gain in memory if you have a lot of pictures stored in a compressed format because QuickTime can only deal with one picture at a time, it will use the same buffer for all the images it has to uncompress.


picture [9]: Hotspots


When your title is loading too slow or is still using too much memory, try to avoid buttons with different states, but do this: Place your buttons onto the background image and just create hotspot/empty objects that handle the necessary button actions. Of course this may not have the desired look, but it can help you in reducing the CD-ROM seek problem.

Remark: Before doing this step, consider using the AMT Accelerator or try to use Flipbooks.

Animation


The following items are only important if you need blazing fast animation in your title. If you are thinking of integrating animation into your AMT title please first consider the third party engine XMeDIA of The Carl Group. This engine offers a lot of new features for standard animations. If the speed is not what you want, then take a look at these tips below.

picture [10]: Position/size

As you may have noticed drawing an image to the screen is mostly moving bytes from one memory location to another. Today's processors are optimized for doing these kinds of operations, but they act better in certain situations. For example, the 68K processors are optimized for moving bytes in a multiple of 4 bytes and also start at a location of a multiple of 4. What this means for multimedia:
When your title is running in 256 colors, the position of the X coordinate of your picture must start at a multiple of 4. Also the width of your picture must be a multiple of 4.

By doing this your title won't use more memory because the OS is doing this internally already when it creates a buffered image.


picture [11]: Transparent

A transparent image takes more time to draw to the screen. First of all, try to avoid big pictures that are transparent if you want to do fast animation. In some circumstances you don't need transparency. For example, when you have a turning globe that stays at a fixed location on screen or if you have a sprite that is moving over a one-color area. In these circumstances, you can just set the sprite's background to be the same as what is supposed to be showing underneath.


picture [12]: Alter drawing mechanism

As we explained before, the AMT drawing mechanism first draws all the elements to an invisible window and then copies the result to the screen. If you have a small sprite running around the screen you don't have to pass by the offscreen. In these circumstances you can double your drawing speed.

picture [13]: Custom blitting/sprites

For AMT 1.2 there exist source code to create custom blitting (or drawing) algorithms. By using these routines you can dramatically increase the speed of drawing. These custom algorithms existed only for the MacOS, but now, with Windows 95, the port of these blitting routines is far easier. These blitting routines have a better way of handling transparent pictures, but this is at the cost of more memory usage.

 

Other resources

FAQ QuickTime Charles Wiltgen Frequently asked questions about QuickTime: http://www.QuickTimeFAQ.org/, current version is 0.45

Tricks of the Mac Game Programming Gurus If you want to create fast animations in AMT yourself, I recommend you read this book. It contains an overview of most of the techniques + source code.

Tools

DeBabelizer 1.6.5 The interface is rather difficult but has some very powerful features. It allows you to do batch processing. It can compress your PICT files as QuickTime Stills (= compressed PICT) with any QuickTime codec. It also supports plug-ins from PhotoShop. This application can read a lot of different image formats. Any professional multimedia developer uses this. It has also some nice features to create flipbook images. ( Price: ???)
PhotoFlash v2.0.1 Has some elegant features, but looks like a PhotoShop lite program. What is great about this package: it supports AppleScript so you can do a list of operations on a series of pictures. (Price: ???)
PhotoShop + PhotoMatic PhotoMatic is a free extensions (http://www.daystar.com) that adds some scripting to PhotoShop. It even has an application that allows you to do batch processing. (free)
Picture Compressor v 1.0 This application came with the first version of QuickTime. It allows you to compress PICT files with any QuickTime compressor codec. (It is free)
GraphicsConverter 2.4 It converts pictures to different formats. Also it contains many useful features for picture manipulation. Allows you to convert a whole folder at once. Can also convert your PICTs to PICTs compressed with a QuickTime codec.(Shareware: $35).
PictMerger.SIT Written by J. Brander, this application allows you to combine several pictures in one pict, this tool is much easier to create Flipbooks then Debabelizer. You can find it on Mark Fleming's ftp-site: ftp://ftp.ccs.queensu.ca/pub/macintosh/amt2.0/